Crate portable_atomic 

Portable atomic types including support for 128-bit atomics, atomic float, etc.

• Provide all atomic integer types (Atomic{I,U}{8,16,32,64}) for all targets that can use atomic CAS. (i.e., all targets that can use std, and most no-std targets)
• Provide AtomicI128 and AtomicU128.
• Provide AtomicF32 and AtomicF64. (optional, requires the float feature)
• Provide AtomicF16 and AtomicF128 for unstable f16 and f128. (optional, requires the float feature and unstable cfgs)
• Provide atomic load/store for targets where atomic is not available at all in the standard library. (RISC-V without A-extension, MSP430, AVR)
• Provide atomic CAS for targets where atomic CAS is not available in the standard library. (thumbv6m, pre-v6 Arm, RISC-V without A-extension, MSP430, AVR, Xtensa, etc.) (always enabled for MSP430 and AVR, optional otherwise)
• Provide stable equivalents of the standard library’s atomic types’ unstable APIs, such as AtomicPtr::fetch_*.
• Make features that require newer compilers, such as fetch_{max,min}, fetch_update, as_ptr, from_ptr, AtomicBool::fetch_not and stronger CAS failure ordering available on Rust 1.34+.
• Provide workaround for bugs in the standard library’s atomic-related APIs, such as rust-lang/rust#100650, fence/compiler_fence on MSP430 that cause LLVM error, etc.

portable-atomic version of std::sync::Arc is provided by the portable-atomic-util crate.

Usage

Add this to your Cargo.toml:

[dependencies]
portable-atomic = "1"

The default features are mainly for users who use atomics larger than the pointer width. If you don’t need them, disabling the default features may reduce code size and compile time slightly.

[dependencies]
portable-atomic = { version = "1", default-features = false }

If your crate supports no-std environment and requires atomic CAS, enabling the require-cas feature will allow the portable-atomic to display a helpful error message to users on targets requiring additional action on the user side to provide atomic CAS.

[dependencies]
portable-atomic = { version = "1.3", default-features = false, features = ["require-cas"] }

(Since 1.8, portable-atomic can display a helpful error message even without the require-cas feature when the rustc version is 1.78+. However, the require-cas feature also allows rejecting builds at an earlier stage, we recommend enabling it unless enabling it causes problems.)

128-bit atomics support

Native 128-bit atomic operations are available on x86_64 (Rust 1.59+), AArch64 (Rust 1.59+), riscv64 (Rust 1.59+), Arm64EC (Rust 1.84+), s390x (Rust 1.84+), and powerpc64 (nightly only), otherwise the fallback implementation is used.

On x86_64, even if cmpxchg16b is not available at compile-time (Note: cmpxchg16b target feature is enabled by default only on Apple, Windows (except Windows 7), and Fuchsia targets), run-time detection checks whether cmpxchg16b is available. If cmpxchg16b is not available at either compile-time or run-time detection, the fallback implementation is used. See also portable_atomic_no_outline_atomics cfg.

They are usually implemented using inline assembly, and when using Miri or ThreadSanitizer that do not support inline assembly, core intrinsics are used instead of inline assembly if possible.

See the atomic128 module’s readme for details.

Optional features/cfgs

portable-atomic provides features and cfgs to allow enabling specific APIs and customizing its behavior.

Some options have both a feature and a cfg. When both exist, it indicates that the feature does not follow Cargo’s recommendation that features should be additive. Therefore, the maintainer’s recommendation is to use cfg instead of feature. However, in the embedded ecosystem, it is very common to use features in such places, so these options provide both so you can choose based on your preference.

How to enable cfg (click to show)

One of the ways to enable cfg is to set rustflags in the cargo config:

# .cargo/config.toml
[target.<target>]
rustflags = ["--cfg", "portable_atomic_unsafe_assume_single_core"]

Or set environment variable:

RUSTFLAGS="--cfg portable_atomic_unsafe_assume_single_core" cargo ...

• fallback feature (enabled by default)
  Enable fallback implementations.

  This enables atomic types with larger than the width supported by atomic instructions available on the current target. If the current target supports 128-bit atomics, this is no-op.

  This uses lock-based fallback implementations by default. The following features/cfgs change this behavior:

  • unsafe-assume-single-core feature / portable_atomic_unsafe_assume_single_core cfg: Use fallback implementations that disabling interrupts instead of using locks.

• float feature
  Provide AtomicF{32,64}.

  If you want atomic types for unstable float types (f16 and f128), enable unstable cfg (portable_atomic_unstable_f16 cfg for AtomicF16, portable_atomic_unstable_f128 cfg for AtomicF128, there is no possibility that both feature and cfg will be provided for unstable options.).

ⓘ Note

• Atomic float’s fetch_{add,sub,min,max} are usually implemented using CAS loops, which can be slower than equivalent operations of atomic integers. As an exception, AArch64 with FEAT_LSFE and GPU targets have atomic float instructions and we use them on AArch64 when lsfe target feature is available at compile-time. We plan to use atomic float instructions for GPU targets as well in the future.
• Unstable cfgs are outside of the normal semver guarantees and minor or patch versions of portable-atomic may make breaking changes to them at any time.

• std feature
  Use std.

• require-cas feature
  Emit compile error if atomic CAS is not available. See Usage section for usage of this feature.

• serde feature
  Implement serde::{Serialize,Deserialize} for atomic types.

  Note:

  • The MSRV when this feature is enabled depends on the MSRV of serde.

• critical-section feature
  Use critical-section to provide atomic CAS for targets where atomic CAS is not available in the standard library.

  critical-section support is useful to get atomic CAS when the unsafe-assume-single-core feature (or portable_atomic_unsafe_assume_single_core cfg) can’t be used, such as multi-core targets, unprivileged code running under some RTOS, or environments where disabling interrupts needs extra care due to e.g. real-time requirements.

ⓘ Note

• When enabling this feature, you should provide a suitable critical section implementation for the current target, see the critical-section documentation for details on how to do so.

• With this feature, critical sections are taken for all atomic operations, while with unsafe-assume-single-core feature some operations don’t require disabling interrupts. Therefore, for better performance, if all the critical-section implementation for your target does is disable interrupts, prefer using unsafe-assume-single-core feature (or portable_atomic_unsafe_assume_single_core cfg) instead.

• It is usually discouraged to always enable this feature in libraries that depend on portable-atomic.

  Enabling this feature will prevent the end user from having the chance to take advantage of other (potentially) efficient implementations (implementations provided by unsafe-assume-single-core feature mentioned above, implementation proposed in #60, etc.). Also, targets that are currently unsupported may be supported in the future.

  The recommended approach for libraries is to leave it up to the end user whether or not to enable this feature. (However, it may make sense to enable this feature by default for libraries specific to a platform where other implementations are known not to work.)

  See also .

  As an example, the end-user’s Cargo.toml that uses a crate that provides a critical-section implementation and a crate that depends on portable-atomic as an option would be expected to look like this:

  [dependencies]
  portable-atomic = { version = "1", default-features = false, features = ["critical-section"] }
  crate-provides-critical-section-impl = "..."
  crate-uses-portable-atomic-as-feature = { version = "...", features = ["portable-atomic"] }

• Enabling both this feature and unsafe-assume-single-core feature (or portable_atomic_unsafe_assume_single_core cfg) will result in a compile error.

• The MSRV when this feature is enabled depends on the MSRV of critical-section.

• unsafe-assume-single-core feature / portable_atomic_unsafe_assume_single_core cfg
  Assume that the target is single-core and privileged instructions required to disable interrupts are available.

  • When this feature/cfg is enabled, this crate provides atomic CAS for targets where atomic CAS is not available in the standard library by disabling interrupts.
  • When both this feature/cfg and enabled-by-default fallback feature is enabled, this crate provides atomic types with larger than the width supported by native instructions by disabling interrupts.

⚠ Warning

This feature/cfg is unsafe, and note the following safety requirements:

• Enabling this feature/cfg for multi-core systems is always unsound.

• This uses privileged instructions to disable interrupts, so it usually doesn’t work on unprivileged mode.

  Enabling this feature/cfg in an environment where privileged instructions are not available, or if the instructions used are not sufficient to disable interrupts in the system, it is also usually considered unsound, although the details are system-dependent.

  The following are known cases:

  • On pre-v6 Arm, this disables only IRQs by default. For many systems (e.g., GBA) this is enough. If the system need to disable both IRQs and FIQs, you need to enable the disable-fiq feature (or portable_atomic_disable_fiq cfg) together.
  • On RISC-V without A-extension, this generates code for machine-mode (M-mode) by default. If you enable the s-mode feature (or portable_atomic_s_mode cfg) together, this generates code for supervisor-mode (S-mode). In particular, qemu-system-riscv* uses OpenSBI as the default firmware.

  Consider using the critical-section feature for systems that cannot use this feature/cfg.

  See also the interrupt module’s readme.

ⓘ Note

• It is very strongly discouraged to enable this feature/cfg in libraries that depend on portable-atomic.

  The recommended approach for libraries is to leave it up to the end user whether or not to enable this feature/cfg. (However, it may make sense to enable this feature/cfg by default for libraries specific to a platform where it is guaranteed to always be sound, for example in a hardware abstraction layer targeting a single-core chip.)

• Enabling this feature/cfg for unsupported architectures will result in a compile error.

  • Armv6-M (thumbv6m), pre-v6 Arm (e.g., thumbv4t, thumbv5te), RISC-V without A-extension, and Xtensa are currently supported. (Since all MSP430 and AVR are single-core, we always provide atomic CAS for them without this feature/cfg.)
  • Feel free to submit an issue if your target is not supported yet.

• Enabling this feature/cfg for targets where privileged instructions are obviously unavailable (e.g., Linux) will result in a compile error.

  • Feel free to submit an issue if your target supports privileged instructions but the build rejected.

• Enabling both this feature/cfg and critical-section feature will result in a compile error.

• portable_atomic_no_outline_atomics cfg
  Disable dynamic dispatching by run-time CPU feature detection.

  Dynamic dispatching by run-time CPU feature detection allows maintaining support for older CPUs while using features that are not supported on older CPUs, such as CMPXCHG16B (x86_64) and FEAT_LSE/FEAT_LSE2 (AArch64).

  See also the atomic128 module’s readme.

ⓘ Note

• If the required target features are enabled at compile-time, dynamic dispatching is automatically disabled and the atomic operations are inlined.
• This is compatible with no-std (as with all features except std).
• On some targets, run-time detection is disabled by default mainly for compatibility with incomplete build environments or support for it is experimental, and can be enabled by portable_atomic_outline_atomics cfg. (When both cfg are enabled, *_no_* cfg is preferred.)
• Some AArch64 targets enable LLVM’s outline-atomics target feature by default, so if you set this cfg, you may want to disable that as well. (However, portable-atomic’s outline-atomics does not depend on the compiler-rt symbols, so even if you need to disable LLVM’s outline-atomics, you may not need to disable portable-atomic’s outline-atomics.)
• Dynamic detection is currently only supported in x86_64, AArch64, Arm, RISC-V, Arm64EC, and powerpc64. Enabling this cfg for unsupported architectures will result in a compile error.

Related Projects

• atomic-maybe-uninit: Atomic operations on potentially uninitialized integers.
• atomic-memcpy: Byte-wise atomic memcpy.

Re-exports

pub use core::sync::atomic::Ordering;

pub use core::sync::atomic::compiler_fence;

pub use core::sync::atomic::fence;

Modules

hint

Re-export of the core::hint module.

Macros

cfg_has_atomic_8

cfg_has_atomic_16

cfg_has_atomic_32

cfg_has_atomic_64

cfg_has_atomic_128

cfg_has_atomic_cas

cfg_has_atomic_ptr

cfg_no_atomic_8

cfg_no_atomic_16

cfg_no_atomic_32

cfg_no_atomic_64

cfg_no_atomic_128

cfg_no_atomic_cas

cfg_no_atomic_ptr

Structs

AtomicBool

A boolean type which can be safely shared between threads.

AtomicF16float and portable_atomic_unstable_f16

A floating point type which can be safely shared between threads.

AtomicF32float

A floating point type which can be safely shared between threads.

AtomicF64float

A floating point type which can be safely shared between threads.

AtomicF128float and portable_atomic_unstable_f128

A floating point type which can be safely shared between threads.

AtomicI8

An integer type which can be safely shared between threads.

AtomicI16

An integer type which can be safely shared between threads.

AtomicI32

An integer type which can be safely shared between threads.

AtomicI64

An integer type which can be safely shared between threads.

AtomicI128

An integer type which can be safely shared between threads.

AtomicIsize

An integer type which can be safely shared between threads.

AtomicPtr

A raw pointer type which can be safely shared between threads.

AtomicU8

An integer type which can be safely shared between threads.

AtomicU16

An integer type which can be safely shared between threads.

AtomicU32

An integer type which can be safely shared between threads.

AtomicU64

An integer type which can be safely shared between threads.

AtomicU128

An integer type which can be safely shared between threads.

AtomicUsize

An integer type which can be safely shared between threads.